這篇是Android開發的最後一篇文章，下一篇就開始了未知的新世界了。
筆者這篇想談一下跟Android無關的軟體開發流程。為什麼要談這個？
因為筆者工作數年後，深刻發現軟體開發流程（又或者稱為軟工），
雖然跟開發完全沒什麼關係，"但是"卻可以深深的影響整個開發，
因此這篇我想提出來探討，這篇是用來分享筆者"目前"
認為比較正確的軟體開發流程，但就僅止一篇。
一個好的軟體開發流程應該如下：
需求分析(Require)-> 系統分析(SA) ->
系統設計(SD) ->程式實作(PG) ->
程式白箱測試(CI/自我測試)-> 程式黑箱測試(Test) ->
程式持續部屬迭代(CD) -> 問題回饋(Feedback)
-> 區分Bug or Feature ->
Bug進入Reproduce And 增加 test case，
Feature則是進入下一次的需求分析(循環)
從這連串的流程來看，可以發現如果今天軟體開發出了問題，
那可以斷定大抵上，不會只是程式實作那一個部分的問題。
但是…筆者遇到的開發問題，
最後通常都是程式實作的人直接負責，主管間接負責，老闆賠錢了事。
但損失最多的會是誰？筆者覺得其實會是公司內的全部人，
因為整個公司組織的每個人，浪費了時間歲月。
但為什麼整個組織很多時候不懂或不想改變這些？
筆者覺得不是本篇想說的事，就此略過。
筆者因為出身關係，覺得軟體開發工程有時像是建築工程一樣，
有時又像是畫家或是工藝師，也剛好有書本在談這塊：
有時候開發時遇到PM or SA説：
開發不用規格書就可以開發了，你不懂如何開發，是因為你能力不足。
聽到的時候真的是蠻傻眼的…
難道蓋一棟房子，不用先把建築設計圖設計好，材料估好，
建築師蓋章，土木技師蓋章，卻希望工人可以自己把房子蓋成101大樓…
好，我們不管在哪裡工作可能都會遇到這些問題，最好的方式是什麼？
坦白說，筆者也還在摸索，但很明確地，
如果想真的做好一個自己認同的產品，
繼續培養自己的核心競爭力，把程式越寫越好，是必須的。
而其他的開發技能，筆者認為也必須逐步必備。
至於瀑布流？敏捷開發？哪個比較好？
筆者覺得最重要的還是回歸到人。
這個組織如何的被建立，大家是否認同以及願意學習成長。
如何營運這個環境，就是每個稍有經驗的工程師的責任了，
願不願意真實的面對問題，向上管理、橫向溝通、向下領導，
與接觸到的工作同仁一同學習成長，
如何學習欣賞每個人的優點以及合作，
最終的目的，其實是為了把產品做好，
而且可以準時上線交付，僅此。
建築工法畢竟發展了一千多年，因此比較穩定，
而軟體工程則才剛起步，而且他有時候又像是一門藝術，
但不論如何，筆者相信未來會更好的，共勉之。
本文同步發佈在Medium，連結在此。
iThome鐵人賽
看影片追技術